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Abstract. Web Operating Systems can be seen as an extension of tra- 
ditional Operating Systems where the addresses used to manage files 
f^ and execute programs (via the basic load/execution mechanism) are ex- 

^-H tended from local filesystem path-names to URLs. A first consequence 

^^ is that, similarly as in traditional web technologies, executing a program 

Cn at a given URL, can be done in two modalities: either the execution 

^..^ is performed client-side at the invoking machine (and relative URL ad- 

C^ dressing in the executed program set to refer to the invoked URL) or it 

^T| is performed server-side at the machine addressed by the invoked URL 

^^ (as, e.g., for a web service). Moreover in this context, user identification 

f" — ■ for access to programs and files and workflow-based composition of ser- 

04 vice programs is naturally based on token/session-like mechanisms. We 

propose a middleware based on client-server protocols and on a set prim- 
itives, for managing files/resources and executing programs (in the form 
of client-side/server-side components/services) in Web Operating Sys- 
tems. We formally define the semantics of such middleware via a process 



^ algebraic approach. 

^H 1 Introduction 

> 

•/"J The widespread use of more and more powerful mobile devices, like smartphones, 

^^ in addition to personal laptops, laptops used at work, etc... has led to the need 

of exploiting the Internet as a repository for storying personal information and 
applications/programs so to be able to use them from any of these devices, not 
to loose them in the case one of these devices is destroyed/stolen and not have to 
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f^ re-install/rc-configure them when such personal devices are changed: personal 

^— I cellphones/smartphones tend, e.g., to be changed much more frequently than 

L| laptops. These needs have led to the recent development of CLOUD comput- 

ing which shifts all resource managing from local machines to a remote (set of) 
server(s) located somewhere in the Internet. Such a trend is, however, influenc- 
ing much more deeply the way in which people use personal computers: browsers 
are, by far, the most used computer application and play, more and more, the 
role of operative systems, which allow the user to use application/programs and 
retrieve/store information. Another reason of this trend is related to the capabil- 
ity of (web) applications and information deployed in the Internet to be shared 
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among several users, thus allowing for cooperation and enhanced communica- 
tion. Examples are Google web applications (Google docs) and social networks 
like Facebook. 

Being the computing experience and the evolution of computer languages/technology 
more and more related to just the browser, this naturally leads to the idea of: 
from the one hand making its functionalities to become part of the operat- 
ing system, from the other hand getting free from the more traditional (and 
heavy) way of installing and configuring applications. In essence, the shift from 
traditional operating systems to so-called Web Operating Systems consists in 
changing from usage of local filesystem path-names to manage files and execute 
programs (via the basic load/execution mechanism) to usage of URLs. A first 
consequence is that, similarly as in traditional web technologies, executing a 
program at a given URL, can be done in two modalities: either the execution 
is performed client-side at the invoking machine (and relative URL addressing 
in the executed program set to refer to the invoked URL) or it is performed 
server-side at the machine addressed by the invoked URL (as, e.g., for a web 
service). From the viewpoint of application development and execution, WEB- 
OS allows applications to be deployed anywhere in the Internet and used from 
any machine by exploiting a front-end/back-end philosophy typical of web ap- 
plications. In WEB-OSes a typical application will have a front-end consisting of 
several application components, i.e. a (graphical) user interface, which is executed 
client-side and a back-end which consists of several service components remotely 
executed on the machine where the application is deployed (such a back-end may 
in turn exploit other resources like databases leading to the typical multi-tier 
architecture of classical web technologies). Notice that, thanks to the usage of 
relative URLs in application components, which are resolved relatively to the ro- 
mote directory URL from which the component has been downloaded, they can 
access remote resources/service components in their delploymcnt environment 
independently from the location of their execution environment. For example a 
typical WEB-OS application has two basic forms of file reading/saving: relative 
to the machine where it is deployed (default way of resolving relative addresses) 
or absolute/relative to the machine where the user is using it. 

The aim of this paper is to propose an architecture and a design/implementation 
for a WEB-OS which uses the mechanisms above as the "normal" way for exe- 
cuting and deploying programs (to be used by the local machine or by other ma- 
chines over the Internet) . The idea has been to perform, apart from taking some 
concepts and basic mechanisms from traditional web technologies, a complete 
fresh re-start in developing such a WEB-OS architecture. In particular, while 
mechanisms typical of a browser (and a server) are present, we abandon the us- 
age of HTML as the "central" format (often also a bottleneck) for user-interfacing 
at the client-side, around which the client-side technologies must operate. No- 
tice that presence of HTML in browsers is one of the main reason that led to 
the current success of interpretation/javascript based client-side web technolo- 
gies over the virtual machine based ones like, e.g., Java applets. In a WEB-OS, 
where execution/development of web applications, becomes the "normal" way of 



executing/developing applications, we believe that interpreted technologies and 
HTML are no longer adequate as the only user-interface technologies. Front- 
end of applications are more naturally implemented by virtual-machine based 
graphical user interfaces, so to have interfaces with the same quality as the tra- 
ditional standalone OSes applications. Such a belief is also along the lines of 
current technology trends: application development in smartphones (which use 
graphical interfaces) and development of rich Internet application development 
where execution outside the browser is often considered a preferred feature (e.g. 
in Java by using the Java Web Start feature). 

A confirmation that the current trend is bringing towards the development of 
WEB-OSes and, more in general, platforms for executing installation-free appli- 
cations deployed in the Internet which remotely preserve configuration and data, 
is given by the very recent presentation of the Google Chromium OS [5] , which 
has been developed concurrently with the ideas/implementations presented in 
this paper. From the available information it seems however that such an OS 
does not follow the "radical" approach taken in this paper and somehow re- 
sambles browser functioning also on usage of HTML pages. A consequence is 
that it considers usage of interpreted/javascript technologies as the client-side 
application front-ends (as in Google docs). 

The WEB-OS architecture presented in this paper, while being freely de- 
signed from skratch, allows for any current clicnt-side/server-side web technol- 
ogy/languages to be used in developing front-end/back-end of programs (both 
interpreted and virtual-machine based for the front-end, of arbitrary nature for 
the back-end) and any possible format for data exchanged (XML, Java object 
streaming. Javascript JSON, etc.). The idea is to have a language/technology 
and data format independent middleware and an extensible set of client/server 
plug-ins one for each of the supported technologies, which are used to interface 
the middleware to application/service components developed with such a tech- 
nology. We propose a model of such a middleware based on: a set of primitives 
for managing files and executing programs in WEB-OSes; and mechanisms for 
application/service component (un) deployment and execution. 

In such a middleware, an important role is played by session managing 
as a mean for user authentication and for the realization of complex work- 
flow/business process patterns [S]. To this end we will also consider session 
delegation as a basic mechanism of the WEB-OS middleware. 

After presenting the basic architecture of the middleware we will propose 
a service-based implementation for it which uniformly combines file/resource 
managing with service component remote execution. We will do this by devel- 
oping an extension (both at the conceptual and at the technical level) of restful 
Web-Services [3] which use HTTP and its request methods as the communi- 
cation protocol. The adequateness of this implementation is confirmed by the 
current success and widespread use of restful Web-Services and of HTTP POST 
for interface-based service components combined with session-like mechanisms 
(based on session id or authentication token). Facebook and Twitter are, e.g., 
endowed with a wide set of services that are in this form. 



In order to unambiguously present the behaviour/semantics of such a middle- 
ware and of applications it executes, we use a process algebraic [6)1|4) approach 
to formally define the semantics of the middleware primitives and component 
deployment/execution. The process algebra that we present is, to the best of 
our knowledge, the first one representing (via URL managing) the behaviour of 
restful Web Services (furthermore it extends such behaviour) and the first one 
managing (via primitives which do not deal explicitly with session identifiers as 
data) sessions in the form of pairs: session identifier and context/application it 
refers to. 

The paper is structured as follows. In Sect. 2 we present the basic WEB-OS 
architecture, in Sect. 3 we present the service-based implementation, in Sect. 4 
we present the formalization with the process algebra. In Sect. 5 we make some 
concluding remark. 

2 Basic Architecture 

We now need to introduce some terminology on URLs that we will use to present 
the basic architecture of the WEB-OS. 

URLs can be of two kind: URLs ending with "\" , F] representing resource 
collections (directories) and URLs ending with an identifier, representing a single 
resource (e.g. a file). A URL of the first kind can be used as a "6ase URL" that 
includes several resources whose "URLs" have such a base URL as a syntactical 
prefix. A particular case of base URL is a "context URL" that is used to denote 
all the resources and services belonging to an entire (web) Application. We will 
also use the intuitive (even if a little improper) terminology of "relative URL" as: 
a pathname (an alternated sequence of names and "\" characters) starting with 
a "\" or not. In the former case the relative URL is called, more specifically, a 
"root relative URL" : when the former is resolved against a base URL, we get an 
absolute (i.e. non-relative) URL by replacing the (non-context) pathname part 
of the base URL with that of the root relative URL; when, instead, the latter 
is resolved against a base URL, we get an absolute URL by just concatenating 
the two (or by performing the preliminar name eliminations in the case ".." are 
used). These notions will be formalized in Section 4. 

Another important notion that we will use is that of session. We will assume 
that each (web) Application uses sessions (session identifiers) to maintain data 
associated with client sessions via a technology dependent data structure (e.g. for 
Java based technologies, session attributes containing objects). As quite usual, 
we will consider each Application (identified by a context URL) to independently 
manage sessions, which, hence, have application scope. From the client side, 
therefore, session information will be collected as set of pairs composed of a 
session id and the context URL the id refers to. 

Figure [T] shows the WEB-OS architecture. The upper part of the figure shows 
deployed /active, i.e. under execution or waiting for method calls, application 



^ For denotational convenience, in this paper we use backslashes in URLs instaed of 
slashes, because we use slashes to represent replacements. 
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Fig. 1. Basic WEB-OS architecture 



and service components (assuming that apphcation components, that interact 
with the user by, e.g., some graphical user interface, have been instahed by 
downloading them from some "Base URL" ) . 

Concerning the lower part, the language/technology independent middleware 
receives (via API) request to execute commands from application and service 
components. All such commands (that we will list in the following) receive as 
argument a (possibly empty) typed data stream (file) and return a (possibly 
empty) typed data stream (file) . The file type determine the format of its content 
and can be implemented, e.g., by using the mime- type standard. Additional 
arguments of such commands are the command destination (absolute or relative) 
URL and session delegation set. The latter is a set of context URLs whose client 
sessions (if detained by the component execution calling the command) are to 



be passed, besides the client session related to the destination URL (standard 
session managing), to a component which is, possibly, executed as the effect 
of the command. As we will see, the middleware maintains a set of detained 
client sessions (pairs session id and related context URL) for each execution of 
an (application or service) component. Client sessions arc therefore not shared 
between components or between different execution of methods in the same 
service component, differently from what happens, e.g., in a browser. 

Relative addresses are resolved differently depending on the invoking compo- 
nent: If it is an application component than the address is resolved against the 
code-base URL (i.e. the URL of the directory the application component was 
downloaded from) which is stored together with the application component when 
it is locally installed (denoted by "Base URL" in the figure). If, instead, it is a 
service component then the address is resolved against the physical-base URL 
i.e. the directory containing the URL used to execute the service component. 

Notice that the technology/language dependent API, which invokes middle- 
ware commands, docs not need to wait to receive the return value from the 
middleware before continuing with the execution of code. It can install an event 
listener (as done e.g. in AJAX) and interface with the middleware in such a way 
that the listener is executed upon completion of the command. Independently 
of the synchronous or asynchronous realization of the API for a particular tech- 
nology, the middleware must be implemented so to be able to manage command 
requests in parallel in that: the client technology may use multithreading and, 
anyway, middleware command requests may come from method executions of 
(different) components, which are run in parallel. 

Middleware basic commands (managing typed stream data) are the following 
ones: 

— Read (inputstream) , write (outputstrcam) or delete file/resources with 
the specified URL: writing creates or modifies and has a typed file as its 
parameter, while a successful reading returns a typed file. 

— Remotely execute an operation of a service component with the specified 
URL: it takes a typed file as the parameter to be passed to the operation 
and returns a typed file as the operation result. 

— Deploy or undeploy service components at the specified local URL: de- 
ployment takes a typed file containing the component code and, if needed, 
deployment infos as the parameter. Undeployment returns a typed file in the 
same form, so to allow for component migration. 

— Locally execute an application component by reading the file with the 
specified URL which contains its code: it takes a typed file containing the 
parameter to be passed to the component execution/initialization and, if 
needed, deployment infos and it returns a typed file containing a local ref- 
erence to the deployed component. 

Optionally, the architecture could also include commands for execution of appli- 
cation component methods (besides direct interaction of the user with the appli- 
cation component user interface). In this case the reference returned by the local 
execution command (and which is then used as a destination address to execute 



methods) must be a "typed" reference, i.e. a reference which makes it possible 
to determine the type of the component. Moreover, deployment/undeployment 
commands could be extended to work on any URL (and not just local ones) so 
to realize romote mechanisms typical, e.g., of a CLOUD system. However it is 
maybe more realistic to think about ronicte (un) deployment of components as a 
higher level mechanism that is not directly implemented by the middleware via 
a unique command and that could be technology dependent in the use of the 
related Internet protocol(s) (it could involve invocation of serveral middleware 
commands in a technology dependent way). 

Command execution is based on direct usage (as a client) of the proto- 
col specified in the URL address and/or, in the case of service components 
(un)deployment and application component local execution (and, if considered, 
of subsequent calls to its methods) , of the middleware functionalities presented 
in the right-hand side of figure [l] 

Concerning client URL protocol invocation, the command performs a request 
containing the typed file parameter, if any, and (by analyzing the client sessions 
detained by the method that invoked the command) : the session id of the client 
session (if any) associated with the destination URL and the session ids of the 
client sessions (if any) associated with the session delegation URL contexts (the 
latter information is passed as pairs session id and related context URL). The 
response, symmetrically, is expected to include, besides a possible typed file or 
error message, a possible new status of the client session related to the destination 
URL (as standard) and of the delegated client sessions (which are delegated 
"back" at the response). The former is returned to the caller of the command, 
while the latter is used to update the status of the set of client sessions detained 
by the method that invoked the command. 

Concerning the right-hand side of figurell] service component (un)deployment 
is based on the type of the component to be (un)deployed (indicating the tech- 
nology/language of the component): in the case of deployment, if the service 
component technology is still not supported by the WEB OS running on the lo- 
cal machine, a remote repository of plug-ins is queried to find a plug-in to install 
in the system so to support the service component technology. For supported 
technologies it uses the corresponding plug-in to perform the (un)deployment 
and it associates the deployment URL (in the configuration of the server of the 
protocol specified in such URL) and the type with the component. Similarly, 
application component local execution is performed by doing, at first, a deploy- 
ment of the application component based on the type of the component to be 
deployed: as for service components, if the application component technology 
is still not supported by the WEB OS running on the local machine, a remote 
repository of plug-ins is queried to find a plug-in to install. Once the applica- 
tion component is deployed by using the plug-in corresponding to its type, the 
component is executed/initialized by exploiting the same plug-in. Before actual 
application component execution, the middleware associates a set of detained 
client sessions to such an execution (which is initialized with standard and dele- 
gated client sessions passed with the command) and maintains it until the end of 



the execution. If subsequent invocations of the apphcation component methods 
are possible, the typed reference identifying the component will cause again the 
same plug-in to be exploited. 

As we already mentioned, the WEB-OS middleware is also endowed with 
server(s) for protocols of URL addresses of files/resources and service compo- 
nents it exposes to the Internet. According to the client invocations we described 
above, such server(s) receive requests to read, write, delete files/resources and to 
remotely execute a method of a service component. Concerning files/resources, 
we just assume that such server(s) perform the required operation by exploiting 
standard OS functionalities (e.g. of the underlying local filesystem manager), 
and, whenever a new file/resource is created the server records its URL and 
its type. The client session passed with the request can be exploited to check 
the identity of the client and its right to manage the file/resources. Concerning 
service components, the server exploits the middleware functionalities to exe- 
cute the required method via the plug-in corresponding to the component type. 
Similarly as for application components, before actual method execution, the 
middleware associates a set of detained client sessions to such a method exe- 
cution (which is initialized with standard and delegated client sessions received 
with the request) and maintains it until the end of the execution. 

Notice that, in the case middleware commands are used that refer to local 
URLs, there is no need to actually perform a protocol client invocation and then 
receive the request from the corresponding local server: in the case the addressed 
URL is local we can avoid invoking the protocol client and, instead, directly 
perform operations on the local resources/filesystem and/or invoke directly the 
right-hand middleware functionalities. 

Finally, concerning the interface of the middleware with the technology/language 
dependent part of the WEB-OS, which is realized by an extensible set of service 
or application technology plug-ins: 

— The (service or application) component code invokes the middleware com- 
mands via a technology /language dependent API which also performs data 
marshalling. 

— The middleware executes (methods of) service or application components by 
performing technology/language dependent required mechanisms and also 
performing data unmarshalling. 

The type of file used for data marshalling (e.g. XML or JSON for Javascript) 
and unmarshlling depends on the plug-in associated with the component type 
and on its configuration. 



3 Service-based Implementation 

We propose a service-based implementation for the basic architecture presented 
in the previous section. In particular the implementation that we propose aims 
at adopting a uniform mechanism for managing both file/resources and service 



components. In the following we will call "operation" a method of a service 
component. 

The needed mechanisms for dealing with files/resources are provided by so- 
called restful Web Services |3] . In Restful Web Services the HTTP protocol and 
HTTP request methods GET,PUT and DELETE are used to manage with the 
resource identified by the URL address of the request. 

In the most simple case the URL corresponds to a local directory /file in the 
destination machine (e.g. according to a mapping from the context part of the 
URL to a directory in the machine filesystem) and the invoked HTTP server 
performs the operation corresponding to the request method: read, write (create 
or modify), delete. 

However, in restful Web Services, URL addresses can be used to represent 
resources different from directory/files, e.g. to directly manage records of a 
database table. The idea is to manage addressed resources via a service compo- 
nent which is associated to a pattern in the form ^\pathname\*^^ : all requests to 
URLs whose (non-context) pathname matches the pattern (where "*" stands for 
any possible suffix) cause an execution of the associated service component which 
possesses an operation for each request method (for simplicity we assume the ex- 
ecuted operation to have the same name of the corresponding request method). 
The operation receives the "suffix" , that in the invoked URL replaces "*" , as a 
parameter and uses it as an identifier for the resource (e.g. a database record) 
on which it actually operates by executing resource specific access code. Notice 
that resource URLs managed by a service component can be of two kind: the 
resource collection kind (the URL ends with "\") and the single resource kind 
(the URL ends with a name). On an URL of the former kind it is possible to also 
use the POST HTTP request method with the following intended behaviour: a 
subresource (a resource whose address is "URL name" or "URL name\" for 
some "name" ) is created whose content is passed as the body of the request (as 
for PUT) and whose name is a "new" (fresh) name established by the server. 

Notice that, in restful Web Services, it is not mandatory for service com- 
ponents to manage several resources: the pattern "\pathname\name" (or just 
"\nam,e") can alternatively be used, which matches just a single resource. In this 
case operations of the service component do not receive a resource identifier, but 
just manage the single resource represented by the only matching URL. 

The interpretation of service components as manager of resources adopted in 
restful Web Services leads to service components endowed with an operation for 
each HTTP method. This approach can be smoothly extended so to encompass 
also interface-based service components, i.e. those of the kind we considered in 
the previous section, which: possess any number of operations with arbitrary 
names, are invoked by specifying the name of the operation and do not possess 
a pre-defined intended semantics. Moreover, this can be done by preserving the 
interpretation of service components as manager of resources. To better under- 
stand this, we make a parallel with object oriented programming. The resources 
managed by a service component can be seen as objects of a class (in this case 
the resource is the memory occupied by object's fields) and service component 



operations as methods defined in the class. In this view, URL suffix identifying 
the resource plays the role of the object reference which is passed to service 
component operations similarly as the reference "this" is passed to class meth- 
ods. Moreover operations with the name (and meaning) of the HTTP request 
methods correspond to getter, putter, constructor and destructor methods, i.e. 
methods which in a class/component have a special pre-defined meaning. The 
presence of such special (related to object resource managing) methods in object 
classes, does not prevent them to also possess (non static) method with arbitrary 
names which act on the object resources in an arbitrarily-defined manner. 

Technically, such user defined operations can be added to the restful Web Ser- 
vice paradigm by exploiting POST requests on single resource URLs: the body 
of the request contains the invoked operation name and the parameter typed 
file; the body of the response the typed file with the return value. By following 
this approach and by continuing the parallel with object oriented programming 
we have that: 

— Statics of a class correspond to collection resources managed by a service 
component, which besides being themselves managed as resources have the 
ability to construct new subresources via POST (as for the static constructor 
method) and return a reference to them. 

— Non-statics of a class correspond to single resources managed by a service 
component, which besides being themselves managed as resources can be 
manipulated by arbitrarily-defined operations invoked via POST. 

Summing up, the service-based implementation is based on the HTTP pro- 
tocol. The middleware commands described in the previous section are imple- 
mented as follows. We have GET, PUT, DELETE commands which cause HTTP 
client requests with the corresponding method to be performed and the REXEC 
(remote execution) command that cause a POST HTTP client request to be 
performed (and the parameter file sent as the request body). LEXEC command 
retrieves the typed file with the application component with a GET request. 
From the HTTP server side, when a request is received, the destination URL 
is checked for matching with patterns of deployed components and, in case of 
successful matching, the longest matching pattern is selected (deployment of 
multiple components with the same pattern is not allowed) and the requested 
operation (that corresponding to the HTTP request method) of the associated 
service component executed, [j 

Notice that, the extension of restful WS we are considering, which allows 
arbitrarily-defined operations to be invoked via POST, makes it meaningful to 
use sessions and session delegation. This because, while in restful WS [3], since 
the only allowed operations on resources are construction, destruction and get- 
ter, putter methods (i.e. those that also in object oriented programming are 
"special" methods with a predefined intended semantics and which provide the 
fundamental mechanisms to manage resources in terms of object memory), it 



This is analogous to the mechanism for determining the servlet to be executed in a 
Tomcat server. 



does not makes sense to make their behaviour/semantics to depend on sessions 
(i.e. on data recorded by previous operation invocations by the same cHent); in 
our extended setting, instead, since we are considering also arbitrarily defined 
additional methods, it is correct to have their semantics to possibly depend on 
data recorded by previous invocations. 

We guarantee that service components possess an operation for each request 
method by defining default behaviours (which are performed in the case no 
operation is explicitly defined) . In the case of GET, PUT, DELETE requests the 
default behaviour is to perform the corresponding action on the local filesystem 
at the corresponding location (according to a mapping of the URL context prefix 
into the local filesystem) and ignoring session information, including delegation, 
passed with the request. Concerning a POST request the default behaviour of 
the invoked component REXEC operation is the following. If the destination 
URL is a resource collection it generates a typed file (or directory) with a fresh 
name in the local filesystem directory corresponding to the destination URL 
containing the body of the request and it responds with the generated name 
(ignoring session information, including delegation, passed with the request); if, 
instead, it is a single resource, it expects the body to be a combined file (e.g. 
a combined mime-type) containing an operation name "op" and a parameter 
file, it invokes operation "op" of the service component and it responds with the 
returned value. 

When defining GET, PUT, DELETE, REXEC operations in service compo- 
nents it is possible to invoke default versions of commands and explicitly pass 
the URL suffix to them, that identifies the resource they must manage. A typical 
use of this pattern is to use the received session to check the identity of the client 
and then to invoke the default behaviour. 

Notice that, it also makes perfectly sense to add arbitrary defined operations, 
besides construction af a new subresource, also to collection resources (which 
would correspond to static methods different from the constructor in object 
oriented programming). This is realizable by just modifying the default behavior 
of REXEC so to manage combined "op" -parameter file requests also on collection 
resources. 

Concerning service component deployment and undcployment commands, 
they must now associate a URL pattern (and not just a single URL) to deployed 
component. 

Some considerations are now in order: the adoption of a resource based ap- 
proach (originating from restful Web Services) allows us to manage general re- 
sources via URL (e.g. databases) and not just files. This is made possible by 
association of patterns to service component identifying the resources that it 
manages, i.e. service components are not identified by URLs which instead just 
represent resources: they are invoked by performing an action on one of the 
resources that they manage. In the case of a single resource pattern the ac- 
tion must be performed on the unique resource that they manage and, only in 
this case, we have a simple scenario where they are accessed by a unique URL. 
Effectively dealing with general resources is also made possible by the restful 



Web Service mechanisni of creation of fresh subresources, i.e. the intended be- 
haviour of HTTP POST on coUection resources. The extension we propose of 
usage of HTTP POST (REXEC) on single resources makes it possible to in- 
tegrate resource managing and service component operation invocation (that 
looked like being dealt with separately in the architecture of the previous sec- 
tion) in a uniform resource-based mechanism. Finally, the capability of managing 
client session and client session delegation (introduced in the previous section) 
makes service component capable to implement complex workflows/businness 
processes. On the other hand practical applications (like facebook and twitter 
services) have shown the importance of user authentication/session managing 
via access tokens/session ids. 

4 Formal Representation of Middleware Behaviour 

We will now present the process algebra formalization for WEB-OS application 
behaviour which encompasses formalization of the middleware primitives and 
API invocation mechanisms. 

In order to be able to cope with all the mechanisms we will make the following 
assumptions that allow for a more uniform treatment: 

— Application components are deployed in the same way as service components: 
their reference is single pattern URL that can be used to invoke their methods 
via REXEC. Such methods can be used to abstractly represent interaction 
of the user with the components. 

— Deployment/undeployment is performed by simple PUT and DELETE com- 
mands at special (local or non-local) URLs dedicated to delpoyment of appli- 
cation and service components (that act as manager of the resources located 
at the associated URL pattern). GET can be used for component migration. 

— Commands in the process algebra are prefixes that wait for completion be- 
fore performing the continuation code. This is meant to represent the be- 
haviour of commands at the middleware level. If we are representing a tech- 
nology/language with an asynchronous API we need to explicitly express in 
the process algebraic specification the asynchronous behaviour of the API 
with: multithreading and communication related to notification of command 
completion. 

4.1 Syntax 

We use x,y, . . . to denote generic names (identifiers) over a set JV. Moreover we 
use I, I' to denote locations overa set C. Locations represent application contexts, 
i.e. a location I identifies both a server (IP address -f- port) and one of its 
application contexts. 

The process algebra is an extension of pi-calculus [6 that represents the 
Internet as a network N of resources R deployed at some URL url: "[-Rjjjr;"- 

N::^[R]uri \ N \\ N \ {i^x)N 



The restriction (vx) is used as in pi-calculus to represent the scope of a name 
(i.e. encloses the program/resources that have access to it). 

URLS url are defined as pathnames starting with a context location I. We 
consider a special context directory called exec that we will use to deploy compo- 
nents, i.e. their code and their associated info, as the URL pattern they manage. 

url ::~ hurl\x \ burl\ 

burl ::— I \ /\exec | burl\x 

We now also introduce relative pathes rpath that will be used in the following, 
e.g., to represent "URL suffixes" which identify a resource belonging to a given 
pattern 

rpath ::— bpath \ bpath x 
bpath ::= e I bpath x\ 
and patterns pat , that will be associated to components 

pat ::— \bpath x \ \bpath x\* 
Resources R can be either values v (typed files) or programs under execution 



P. 



R::^P\v 



We will see the syntax of programs P in the subsection about semantics. Con- 
cerning values V we consider primitive values pval which should at least allow us 
to represent successful and erroneous response from a request an numbers, names 
X, passive typed (where the type denotes their technology) application compo- 
nents {D)type to be downloaded by LEXEC, deployed components {D)^yp^ -^pat ^ 
pairs a; < w > used to represent combination of operation/method name x and 
parameter value x passed to a REXEC, references ref that we will define in the 
following as URLs or relative pathes, etc.. 

V ::= pval \ x \ {D)type \ {D)'^yp^ ^'"'* \ x < v >\ ref \ . . . 

pval ::— ok | err | num \ . . . 

where url-^ stands for either url or _L. The two cases arise depending if the 
deployed component is an application component (in this case the url represents 
the codebase url) or not. 

D is a declaration of a set of operations op, which are user-defined or com- 
mands, defined by 

op ::= com | x 



com ::= put | get | delete | rexec 



Formally, D is a, partial function from operations op to pairs composed by a 
formal parameter variable x and a term E representing the code of the operation. 
Definitions in D are represented as op{x) — E. Moreover, we assume D to be 

such that, if com(x) — E € D, for com G {get, delete} , then x ^ fr{E) R i.e. 
no value is received by the get and delete operation definitions. In general, in 
the following, we will just use op — E, to stand for a definition op{x) = E such 
that X i fr{E). 

We are now in a position to represent the syntax of terms E, i.e. code defining 
operations. We preliminary need some definitions 

In method code we use urls starting with < session >, < application > 
and < phbase > to manage session attributes of the current application and 
application attributes (for service components) and access the physical base (for 
application components). 

We also use relative pathes starting with < ipath > to access the internal 
path, i.e. the URL suffix identifying the resource on which a service component 
is called. 

References ref are possible way of expressing addresses (relative, root-relative 
or absolute) in a middleware command. 

ref ::— urlg \ rpathg \ \rpath \ \ex.ec\rpath 

where urlg is defined as for url except that burlg replaces burl and rpathg is 
defined as for rpath except that bpathg replaces bpath. The syntax of burlg is as 
that of burl with the additional production 

burlg ::= • • • |< symurl > 

where 

symurl ::= session | application | phbase | x 

The syntax of bpathg is as that of bpath with the additional production 

bpaths ::= • • • |< ipath > 



We also need to introduce expressions. An expression e includes v possibly 
combined with operators and returns a i;. A boolean expression be includes v 
possibly combined with operators and returns a boolean (true or false) . In the 
semantics we will denote evaluation of expressions e/be such that all variables 
(unbound names) have been already instantiated with £{e)/£{be). 

Finally, we need to introduce session delegation sets rs, which specify a set 
of contexts for which we want the client session to be delegated, e included in 
the list is a relative reference to the context of the base URL (codebase for 
application components, physical base for service components). 

rs ::= {rlist} \{}\I 

rlist ::= I, rlist \ I \ e 



We use fr(E) to denote free names included in E. 



Notice that the spacial case X of rs denotes an internal command, i.e. a usage 
of a default command behaviour inside a user defined command/operation. In 
this case the command expects a relative url identifying the resource it must 
work with. 

E :■= X = ^xxtll^ e.E \ 

X =. delete^^^.i; | 

X = rexecj;^ . e.E \ 

X = lexec^g^ e.E \ 

x = e.E\ 

xe.E\ 

x{y).E\ 

spawn E .E\ 

if be then E else E | 

ly < session> .E \ 

—'<session> .E \ 

return e 


where, for commands x ~ cornel f e.E occurring in E, we have that rs = X 
implies 3rpaths : ref = rpathg. 



4.2 Semantics 

In order to present the semantics we need to preliminary define the syntax of 
terms P representing the syntax of programs/operations in execution. 

In order to do this we need to extend the syntax of urls (terms burl), as 
defined in the previous section, so to represent session managing via special 
resources. 



burl ::= • • • | l\extrapath \ x 



extrapath ::— session | session\ns | application 

5 is a metavariable that can stand for a session identifier (a name x or no 
session ns, in the case no session is detained). 

S ::= ns|x 

We need also to introduce session delegation pairs sis that are transmitted 
inside a service request. 
sis ::= {sllist} \{}\I 
sllist ::= I .S, sllist \ l:S 
The syntax of terms P representing operations in execution is as follows. 



^ = S<ri:S-P\ 

X = rexec^J^i.g e.P \ 
X = lexec'J^i.s e.P \ 
x= e.P\ 
x"^" e.P\ 
x{y).P\ 
{i^x)P\ 
spawn P .P\ 
if be then P else P | 
I' l\session\S .P \ 
-^ l\session\S .P \ 

Before presenting the semantics, we need to introduce pathes path as the 
path information that can occur in an url after the context. 

path ::= \rpath \ \ex.ec\rpath \ \extrapath\rpath \ e 

In the following we will use TZ (resource collections) to denote terms N that 
do not include {vn)N subterms. 

The semantics is defined in tables[T][2]|3J|4J[5]and[6) In the tables we assume 
the following definitions. 

— Intg = {?\, /\session\, ^\exec\ | / G £} 

— Intd — {l\ /\application\ | Z e £} 

— maxpat{TZ,path) = max {pat e pats{TZ) \ path g pai}rj 

where pats{n) = U[fl]„,,,g7?,Pa*([-R]"H)- -P«^([-R]«w) = {pat} ii R = (-D)^^"^^^''* 
and url = l\eyiec\m\ for any D, cbase, pat, I and m; pat{[R]uri) = other- 
wise. 

— match{l path, pat, TZ) — Ipath £ urls{TZ)Apath e patApat > maxpat{TZi,path) 

Moreover d{pat) returns the path corresponding to the directory of the pat 
(after that * has been removed), '^ returns the argument on the left if it is not 
_L, otherwise it returns the argument to the right, url{-, _) and l{-, -) perform 
the expected evaluation of an (absolute) url and a context I starting from the 
absolute base url on the left and the relative url on the right, path— pat computes 
the path suffix matching * (or e if there is no *) in the expected way. 

Finally, the boolean function cond is assumed to be any predefined function 
such that, for any context I: cond(Z\session\) = cond{l\ex.ec\) = cond{l\) = 
true. Moreover, loci_type is assumed to be a predefined function that returns a 
context I' located at the same IP (in the same machine) as I, such that I' is 
capable to execute the client-side technology of type type. type{x) determines 



** We assume that e is returned (the smallest element in the prefix relation) if we have 
an emptyest. 



the type of value x: recall that values represent (content of) typed files. Hence 
we have type{{D) type) = type. 

Notice that the negative premise in Table [5] does not cause bad definedness of 
the operational semantics. This because, in the rules for captured commands, the 
capability of a term of performing some auxiliary transition is not conditioned 
on the existence of some reduction transition — >■ (which could in turn depend 
on auxiliary transitions), this because the term N \\ TZ considered in the premise 
can always perform a reduction transition (i.e. the synchronization between op 
and op). 



Table 1. Congruence rules. 



A^i II iVa = iVa || A^i 
(iVi II N2) II N3 = iVi II (iVa II iVs) 
{(vx)N^) II iVa = {ux){N^ II iVa) x i fr{N2) 

[{vx)P]url = {l^x)[P]url 



Table 2. Basic rules. 



N — ^ iV' A iVi = TV iV — > N' 



Ni — > N' {vx)N — > N' 

[x = comtl.se-P]uri' II 7^ -^c 11' 
[x = comtl:5e.P]„H' II 7^ — ^ 7^' 

[x - com°';;,.;e.P]„H' II 7^^, 

[x = com^Vl :se-P]iir;' II 7^ — > [P{err/x}]^ri' II 7^ 
[sTpacwn P.Q]buri\ \\ Tl — ^ t ^ fr{P,burl) 

lQ]burl\\\{{'^t)[P]b^rl\t\)\\ n 

[if 6e then P else Q]„ri || TZ — !> [P]uri || Ti. £{be) = true 
[if be then P else Q]uri \\ TZ — > [Q]uri \\ Ti- £{be) = false 

[0p'''e.P]^rl\\[0p{x).Q]^rl'\\ n—f 

[P]url II [Q{£{e)/x}9^e2\url' \\ 7^ 

01 = {I path -.S' /I path : S \ path € Path A I : S' € sis} 
62 ~ {Z\session\5' / Z\session\5 | I : S' £ sis} 



Table 3. Rules for auxiliary transitions of uncaptured commands. 



X = puttl^^e.PJ^H' II [v'Uri II 7^ 

^e[P{ok/x}]„H'||[^(e)]nH|| 71 
X = put'J;^i.ge. P]^ri' II 7^ d(urZ) G urls{n) U /nid A 

^e [P{ok/a;}]„w' II [£^(e)]„ri || 7^ id{url) ^ id{urls{n)) 
X = gettl.s.P]„w' II H^^ri II 7^ 

-^c[P{v/x}]^^i, II [w]„w II 7^ 
X = delete^'/,. 5. P]„rt/ || H„w |1 Tl ^url" G urls{TZ) : url" > url 

^c [P{ok/x}]„w' II 7^ 

= rexeCtJf^;\^.5e.P]„H' II T^ burl\ G urls{TZ) U Jnfj A 

^c (!^n)([P{n/a;}]„ri' II n <^ fr{{P, e, burl, url'}) 

[^(<^)]6nri\n{\}<=°'"i(*»"-'\)) II ^ 



additional condition for each rule: 

sis = X V fir G 7?. : pat{r) = {maxpat{TZ, url)} A com G ops{r) 

where com is the rule command and url — burl\ for the rexec rule 



Table 4. Rules for auxiliary transitions of captured commands. 

N\\ TZ — ^ 7^' A op{y) ^Q € D A match{l path, pat, TZ) 
op G Com 

[^ = op^l:,^.,s e.PU, II [(D)?^;r"^"*]<\exec\™\ II 7^ ^. 7^' 

Af II 7^ — ^ 7^' A op{y) = Q€ D A match{l path, pat, TZ) "P i Com A 

rexec 4 dom(D) A 

F = rexec,p„i^^5 op < e > .P\uri' II K-Dltype Ji\exec\m\ II !<■ — >c 7^ path = path'\n 

N = ((i.2)([op='»^{'^^>e.2(x).P]„H' II 
(j.i)[op(j/).Qeie2{^='=^^"'^>/reiurn}],yexec\^\A))ll[(^>S;r"'"'*];\exec\™\ 

Si = {i\session\ns / < session >}{Z\application / < application >} 
{I id{d{pat)) I < phbase >}{path — pat / < ipath >} 

6*2 = {a; = comJ^((p„t ,,p„j^)^„^e.P/x = com^p„t;,e.P | x = com^p„t;,e.P G V} 

( {l(cbase'-^l,r):ns\rErs} 7-,/ rs j-y \ rs n ^ Til 

I. url{cbase'^-^l a{pat), re J ):n.s l ^ej I rej ^ J 



Table 5. Rules for sessions. 



[j//\session\5.P]uri || T^ — > [P]uri \\ T^ 5 / ns 

[X = reXeCi\session\:ns-P6'l6'2]uW || 7^ > 7^' ^ , , „, 

X ^ fr(P) 

[ly l\session\ns.P]uri \\ Tl — > TZ' 
6\ — {/\session\a; / /\session\5 | 5 G A/'U {ns}} 
02 = {I path : X / I path : S \ path £ Path A 5 G A/" U {ns}} 



[^/\session\ns.P]uri || TZ — > [P]uri \\ TZ 

[delete;\session\S\:ns--P^1^2]uri || 1Z > TZ 



5 7^ ns 



[^ /\session\5.P]uri || TZ — > TZ' 
6\ — {/\session\ns / /\session\5 j <S G A/" U {ns}} 
02 = {/ path : ns / I path : S | path G Path A 5 G A/" U {ns}} 



Table 6. Rules for local execution. 



[X = get; p„th\n:5-'' = loCl^type{x) ■ 
71 rGXGC//\^ -jis .rGXGC;'\^e3(;ec\:ns'*' 

[y = le^ecf;^,^^„.,se.PUi || 7^ ^ 7^' 



5 Conclusion 

We experimented a Java based partial implementation of the middleware, imple- 
menting our integrated version of interface-based and restful based web services, 
with comet related applications (application that send events in real time to the 
front-end interface) and we tested several solutions base on services keeping re- 
sponses permanently open and long polling solutions. Moreover we experimented 
with the performance of several data binding methods. 
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